1. Technical Field
This invention generally relates to object oriented programming and more specifically relates to an apparatus and method for updating objects in an object oriented system.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware, such as semiconductors, and circuit boards, and software, also known as computer programs. As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the application software programs designed for high performance computer systems have become extremely powerful. Additionally, software development costs have continued to rise because more powerful and complex programs take more time, and hence more money, to produce.
One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object oriented programming concepts. The goal of using object oriented programming is to create small, reusable sections of program code known as "objects" that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a comprehensive set of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
A central concept in object oriented programming is the "class." A class is a template that defines a type of object. A class outlines or describes the characteristics or makeup of objects that belong to that class. By defining a class, objects can be created that belong to the class without having to rewrite the entire definition for each new object as it is created. This feature of object oriented programming promotes the reusability of existing object definitions and promotes more efficient use of program code.
An object in an object oriented computer program typically has attributes defined by state data that determine how the object will behave. State data as used herein defines both methods and data within an object, and is a concept that is well-known to one skilled in the art. If an object is transient, it is created within a process, and terminates when the process ends. If an object is persistent, however, mechanisms are put in place to allow the object to survive the process that creates it so it can be accessed by other processes.
Objects are typically made persistent by storing their state data in a local data store. In many known computer system, the process of making an object persistent is known as "externalization". Externalization is the means or protocol used in object oriented programming for transferring data out of an object. In essence the state data that defines the attributes of an object are "externalized", or written out of the object, into a different format that is easily stored in the local data store. When the object is needed again, the externalized state data is internalized into an object, creating an exact copy of the object as it previously existed.
Computer programs naturally evolve over time. Changing an object oriented program requires changes to objects. When changes to persistent objects are required, there is no uniform mechanism for updating the persistent objects. For example, assume a company has an Employee class that contains the employee's name; address, including 5-digit ZIP code; and home telephone number. Let's further assume that the employee class needs to be updated to incorporate a nine digit ZIP code and to include a department code for the employee. A new class is defined with the additional data fields for the ZIP code and the department. But how is the existing, persistent object updated so that it contains the additional data fields?
Referring to FIG. 2, one known method 200 for updating persistent objects first stores the state of all objects in the system in memory (step 210), generally by externalizing the object data to a data store. Next, all the objects in the system are passivated (step 220). The new class is loaded (step 230), an instance of the new class is created (step 240), and one or more methods on the new class are invoked to retrieve the stored state data (step 250), generally by internalizing the state data into the new instance(s) of the new class. While this method succeeds at updating the persistent objects, it requires that all processes that access the objects to be shut down in order to passivate the objects. With large systems that have thousands or millions of objects, this process can be very time-consuming, and can take a computer system off-line for many hours. Shutting down a large computer system for many hours is an unacceptable solution in many cases. For this reason, a dynamic way of updating objects would be preferred.
Recent developments in object oriented systems allow an object to be updated without being passivated. One such development uses a morph() method to perform the metamorphosis of an object from an old class to a new class. For the discussion herein, the term "morph" is used as shorthand for updating an object from a first class to a second class. Each class has a morph() method that may be invoked to update an object to a new class without passivating the object. Referring to FIG. 3, a method 300 for updating persistent objects using a morph() method starts by building a new class (step 310). Next, all applications that use any of the instances of the old class are stopped (step 320). If the applications were allowed to run during the morphing of the objects, an application could encounter instances of the old class mixed with instances of the new class, which would produce indeterminate results. Next, the morph() method is invoked on each persistent object that needs to be updated (step 330). This morph() method converts the object from the old class to a new class. Once all of the objects have been updated, the applications are re-started (step 340). This type of system overcomes some of the disadvantages of system 200 of FIG. 2, because the thousands or millions of persistent objects may be updated without passivating the objects. However, the applications that use these objects still must be shut down or locked out while the objects are morphed, which may result in unacceptable down-time for many computer systems.
Method 300 of FIG. 3 may be used to update objects when an application requires new methods or data fields in the object. Once the morph() of all applicable objects is complete (step 320), the application may then be run. However, an application that requires updated objects must wait until all of the objects have been morphed before running.
A variation of method 300 might minimize the down-time of certain applications by morphing objects in a background process. This approach would reduce the down-time of the computer system by selecting a relatively small number of objects that need to be morphed, and locking out access to these objects during the morph, which would occur relatively quickly due to the relatively small number of objects involved. In this manner, different applications may be locked from accessing certain objects at certain times, but the time penalty for updating objects is amortized over a longer period using the background process.
All of the methods discussed above for updating persistent objects require an application to be locked out until all objects that the application uses are updated. Locking an application during the updating of all required objects that it references also results in unacceptable down-time for many applications in large-scale object oriented computer systems. Without a mechanism for updating persistent objects without shutting down applications that reference the updated objects or delaying the execution of an application until all referenced objects are updated, the computer industry will continue to suffer from inefficient and costly methods of updating persistent objects in an object oriented computer system.